REMARKS 

Claims 1, 5-6, 8-11, and 13-15 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Yoshikawa in view of Aihara. Applicants have amended claims 
1, 9, and 10 to more clearly define at least an acquiring unit acquiring field attribute data 
indicating, for each field, whether the field is an output field or input-output field and a 
character string defined from screen data of a character-based user interface screen, and a 
determination unit determining whether each of the fields is an output or input-output 
field based on the field attribute data acquired by the acquiring unit. As applied to the 
amended claims, Applicants respectfully traverse the rejection for at least the reason that 
neither reference teaches or suggests at least an acquiring unit and a determination unit as 
defined. Additionally, neither reference teaches or suggests the naming unit defined in 
claims 1, 9, or 10. 

Claim 1 as amended and its dependent claims define, among other things, 

an acquiring unit acquiring field attribute data indicating, for each field, whether the field 

is an output field or input-output field and a character string defined from screen data of a 

character-based user interface screen; a determination unit determining whether each of 

the fields is an output or input-output field based on the field attribute data acquired by 

the acquiring unit; and a naming unit specifying, for the input-output field for which no 

field name is defined in the character-based user interface screen, a control name in a 

graphical user interface screen based on a character string of the acquired field attribute 

data of the output field in a vicinity of the input-output field. Claims 9 and 10 as 

amended, and their respective dependent claims, teach similar or analogous features. 
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These features are neither taught nor suggested in Yoshikawa and Aihara, alone or in 
combination. 

The Office Action states that Yoshikawa describes using a field name, 
"NAME", in a character user interface (CUI) screen as the field name, "NAME", for an 
output field of a graphical user interface (GUI) screen, and that it would be obvious to 
arrive at the claimed invention based on Yoshikawa. However, neither Yoshikawa nor 
the other reference cited, Aihara, discloses or suggests at least specifying control names 
in a manner dependent on names defined for an output field in vicinities of particular 
input/output fields, for input/output fields for which no field names have been defined. 
This difference, for example, allows the invention defined in claim 1 to automatically 
specify new, recognizable control names on a GUI screen for input-output fields. 

According to amended claims 1, 9, and 10, the acquired character string 
from the attribute data is actually used to specify the control name. Coincidence between 
the control name of an input-output field and extracted field information of an output 
field is not sufficient, nor is a "clear relation" or a "clear association", as proposed in the 
Office Action. To teach or suggest these features, a system (or method in claim 9) must 
be specifically shown to acquire a character string defined for an output field and, for an 
input-output field for which no field name is defined in the character-based user interface 
screen, use the acquired character string to specify the control name of the input-output 
field in the GUI screen. Neither Yoshikawa nor Aihara teach or suggest this feature. 

As described in the Background of the present application, before the 

present invention, either control names for GUI fields were mechanically and arbitrarily 
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generated during a conversion process, or a user would select more easily identifiable 
control names manually using a GUI screen editing tool (page 2, lines 6-21). The 
invention disclosed in Aihara appears to include an example of a GUI screen editing tool 
(see col. 6, lines 19-26) for creating source panel and new panel definitions. The 
invention defined in claims 1, 9, and 10, on the other hand, is useful for the case where a 
control name has not been defined for a particular field. The control name generation 
process can be both automatic and useful for providing more easily identifiable control 
names. 

Yoshikawa, as recognized by the Examiner, fails to teach or suggest that 
field information of an output field is used to specify a control name of an input-output 
field. Additionally, Yoshikawa fails to teach or suggest that acquired character string 
information from one type of field can be used to specify a control name for a different 
type of field in any event. Still further, Yoshikawa fails to teach or suggest providing a 
field name for a field of a graphical user interface screen for which no field name is 
defined in the character-based user interface screen. Instead, Yoshikawa appears to teach 
that a field name for one screen (CUI) is used as a field name of the same type for 
another screen (GUI). This field name is pre-assigned as screen definition information 
(see col. 9, lines 23-32); that is, it already exists during the screen conversion process. 
The GUI field name is provided for a field by assigning to a variable F (for "field name") 
a pre-existing identification code for that field from the pre-existing screen definition 
information of the source panel. 
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Particularly, Yoshikawa teaches that, during a conversion process, screen 
definition information 6 is furnished from a host computer 1. This screen definition 
information, an example of which is shown in FIG. 7, defines the names of fields 
included on the screens (col. 6, lines 26-33 and 51-58). This screen definition 
information, including pre-defined field names, is used to analyze screen display 
information 21 to provide a GUI display (see the sequence illustrated in FIG. 5). The 
field name assigned to a variable F is set based on the acquired field name for the fixed 
field that has been pre-assigned in the screen definition for a fixed field (in this case, 
"ABFFNAME"). The field name "ABFFNAME" is already part of the screen definition 
for the fixed field, just as the name "ABFONAME" is already part of the screen 
definition for the output field. 

According to Yoshikawa, screen definition information is used in a 
conventional application processing system (col. 5, lines 44-67). The same screen 
definition information 6 is used in the GUI processing system of Yoshikawa (col. 6, lines 
6-11). Further, nothing in Yoshikawa teaches that the displayed character string of a 
fixed field, the name of the fixed field, or any other part of the fixed field is used to 
specify a name for an input-output field, or any other field besides the field of direct 
correspondence to that field (that is, the fixed field "ABFFNAME"). 

The Office Action suggests that Aihara addresses the deficiencies of 

Yoshikawa because the control names of the input-output fields for "USER ID" and 

"PASSWORD" are "clearly associated" with the character string information of the 

output field. However, claims 1, 9, and 10 define at least that the control name of the 
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input-output field is specified based on an acquired character string of a particular output 
field. The field control name defined is not merely "clearly associated" with such 
information. Further, the claims define that the control name is specified for an input- 
output field for which no field name is defined in the character-based user interface 
screen. 

The Office Action states that Aihara discloses creating a control name 
wherein the control name is based on the field information extracted from the source 
panel and that information is used to create a new control name within the new panel, 
citing col. 7, lines 63-68. Applicants respectfully traverse this statement. The cited 
portion of Aihara merely describes that input areas are named PASSWORD and 
USERID, and correspond to input areas on a new panel (FIG. 7). These same names are 
already given to input fields of the source panel (col. 7, lines 8-12), and both of these sets 
of names are from pre-existing screen definition information. Aihara also discloses that 
the names "password" and "userid" are placeholders within a new panel definition 232. 
These names provide variables for an operation "logon" (see step 1017), which writes the 
results of the input fields filled-in by a user into the input areas of the source panel (as 
shown in FIG. 9). 

Particularly, the source panel definition 231 in Aihara is used as a template 

to analyze the source panel. Steps 902 - 917 describe a procedure for filling in the input 

fields of the source panel based on user inputs from the new panel shown in FIG. 7. The 

input fields 602, 603, 604 of the source panel are already named "USERID", 

"PASSWORD", and "COMMAND", and are pre-defined by a series of coordinates 
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within the original source panel screen (steps 905 - 907). In Aihara, a user interface 
mapping profile 230 includes the source panel definition (FIGs. 8 and 9), the new panel 
definition (FIG. 10), and a mapping definition (FIG. 10). 

Aihara specifically states that the user interface mapping profile 230 is 
expressed in a prescribed tag language, or is simplified by use of a dedicated support 
program that is manipulated by a user (such as by use of a mouse) (col. 6, lines 8-31). 
This means that the source panel definition 231 and the new panel definition 232, 
including the placeholder variable names, the given names for the input areas of the 
source panel (steps 905-907), and the given names of the input areas in the new panel for 
user input (steps 1013-1014, col. 7, lines 66-68), are already created before acquisition of 
the source screen by the user interface mapping profile. Further, any similarity disclosed 
appears to be between input fields of a source panel and input areas of a new panel, not 
between an output field and an input field (see col. 7, lines 11-12). f 

Aihara teaches no method for generating the source panel definition 230 
beyond stating that a tag language can be used, or that a dedicated support program can 
be used. Aihara also does not teach or suggest that the dedicated support program, or a 
tag language generator, performs the acquiring, determining, and naming steps claimed. 

Though Aihara teaches variables "password" and "userid" in a new panel 

and the terms "USERID" and "PASSWORD" in a source panel, Aihara fails to teach a 

system, method, or medium that acquires the character strings "USERID" and 

"PASSWORD" in the source panel of FIG. 6 and uses these acquired character strings to 

create control names for input-output fields in the new panel definition of FIG. 10. As to 
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the depiction in FIG. 7 cited in the Office Action, and any relation between the fields 
shown therein, the output "USER ID..." shown in step 101 1 is separately provided in the 
new panel definition 232 from the entry name "userid" used as a placeholder in step 
1014. Both are pre-defined. 

Finally, regarding the Office Action's response to Applicants' previous 
arguments, Aihara does not disclose that attribute data is acquired from the source panel 
and that output field names are relied upon to create the new input-output field names. 
The Office Action cites col. 7, lines 50-68 to support its statement. However, as 
explained above, this section of Aihara does not teach acquiring attribute data of output 
fields "USERID" and "PASSWORD" from the source panel including a character string, 
but instead teaches pre-defining input areas of the source panel (locations 602 and 604) 
that are filled-in based upon an input of the user into input fields 709 and 710 in FIG. 7. 

For at least these reasons, Applicants respectfully submit that claims 1, 5-6, * 
8-11, and 13-15 are allowable over the references of record. Accordingly, Applicants 
respectfully request reconsideration and withdrawal of the rejection. 
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For all of the foregoing reasons, Applicants believe that this case is in 



condition for allowance, which is respectfully requested. The Examiner should call 
Applicants' attorney if an interview would expedite prosecution. 
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